有人交了一份 SBOM 給客戶。三個月後客戶回信問：這份還準嗎？
答不出來。
因為那份 SBOM 是某個人某天下午掃出來的，之後產品出了兩個韌體版本，沒有人重掃。
**Annex I Part II(1) 要的是一個能力，不是一份檔案。**判準很簡單：如果你的 SBOM 有「產出日期」卻說不清「產出方式」，它是文件；如果每一次建置都自動帶出一份，它才是產線。
格式先決定，因為它決定後面所有事
三個候選：SPDX、CycloneDX、SWID Tags。
選擇準則不用列優缺點，問自己要拿它做什麼就好：
最後一列是重點。**選一個當真相來源，其他都是轉出格式。**兩套各自維護的公司，半年後會發現兩套都不準，而且沒有人知道該信哪一份。
底線是 NTIA 的最小欄位：供應者、元件名稱、版本、唯一識別符、依賴關係、SBOM 作者、時間戳。少一欄，收到的人就得回頭問你。
什麼時候產：三個時機，只有一個站得住
**開發時手工維護一份清單。**它從第一天就開始過期，而且沒有人知道是哪天開始不準的。
**出貨前掃一次。**比手工好，但掃的是成品映像，跟當時的建置環境已經脫節。靜態連結、打包、壓縮都會吃掉資訊。
**建置時自動產出，跟著產出物一起封存。**這是唯一站得住的做法。
理由是對應關係。SBOM 必須對應到那一次建置出來的那一顆韌體，事後掃描重建不出當時的依賴樹。
食品的成分標示是同一個邏輯。標示對應的是那一批，不是對應到那個產品名稱。配方換了、供應商換了，標示就得跟著那一批走。你不會用去年的標示去貼今年的貨。
所以有一句話值得記下來：SBOM 的版本號其實是產品的版本號。
硬體廠的那塊，目前沒有好解法
到這裡為止都是純軟體專案的做法。硬體不一樣。
一顆工業主板的韌體映像裡面有 BSP、bootloader、作業系統、驅動、應用程式，來自不同的來源、不同的建置系統，有些甚至不是你建的。
掃描工具可以掃出一部分，但有三塊掃不到：
靜態連結進去的函式庫看得到符號，看不到版本
晶片商給的二進位檔沒有中繼資料，你只知道檔名
打包後的壓縮或加密層會直接擋住掃描
所以硬體廠的 SBOM 一定是多來源合併：自動掃描的結果、建置系統的宣告、加上供應商提供的清單。
**這三個來源目前沒有一個統一的合併標準，那是真的缺口。**我不打算假裝有解法。掃不到的那塊 Day 21 會從識別符的角度再談一次，要不到的那塊留給 Day 25。
掃描會拖慢建置，但那是排程問題
實務上最大的阻力不在技術，在研發會抗議：「加了這些檢查，建置從十分鐘變成四十分鐘。」
這個抗議是合理的，而且直覺的解法是把掃描往後挪到 release 才做。但那樣你會在最貴的時候才發現問題，改起來的成本是原來的好幾倍。
比較好的方向是按時間成本分層：
還有一件事常被忽略：**這兩層跟編譯測試之間沒有相依關係。**它們不需要等彼此，可以同時跑。
這就是為什麼我說它是排程問題。序列排隊的流程，總時長是各段相加；平行之後，總時長是取最大值。同樣的檢查內容，換一個排法就差很多。
多數人把「掃描很慢」當成效能問題去優化工具，其實該先看的是排隊圖。
至於每一層放什麼、門檻怎麼設、慢的那層多久跑一次，這幾題後面三天各談一天。今天先把問題問對。
交付物：分層設計的六個決策問題
這份刻意不給答案。每家公司的產品線、建置時間、團隊規模都不同，抄別人的參數只會得到別人的問題。
三個提醒。
**第一，第二題請真的去量，不要問工程師「大概多久」。**體感時間跟實際時間的落差通常很大，而且是雙向的。
**第二，第五題是最容易被跳過、也最致命的一題。**一個沒有放行機制的門檻，第一次擋到緊急發版的時候就會被人整個關掉，然後再也沒有打開。設計門檻的時候就要一起設計例外。
**第三，第一題答完之後，你可能會發現現有的檢查有一半不該擋。**那些改成「記錄但不阻擋」，建置時間立刻就降下來，而且你什麼都沒有少做。
明天 Day 21：HBOM，硬體廠獨有的那一張表
軟體物料清單的那套識別符，到了硬體上為什麼對不起來。現有標準走到哪裡、缺口在哪裡，以及在標準補上之前可以怎麼過渡。
順便問一句。你們現在最新出貨的那個韌體版本：
有沒有一份跟它一一對應的 SBOM？
（a）有，建置時自動產的 （b）有，但是人工掃的 （c）有 SBOM，但不確定對應哪個版本 （d）還沒有
留個字母就好，不用打長篇。（c）其實比（d）危險，因為它會讓人以為這件事已經做完了。
這系列每天更新，覺得有用的話訂閱一下，我盡量不寫廢話。
參考：Regulation (EU) 2024/2847 Annex I Part II(1)(3)；SPDX（ISO/IEC 5962）、CycloneDX、SWID Tags；NTIA 最小基本要素。分層設計與六個決策問題為個人整理，尚未經導入驗證，非法規明文。
iThome鐵人賽
看影片追技術